Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tag support to LogGroup resource #53

Merged
merged 7 commits into from
May 20, 2021

Conversation

gruebel
Copy link
Contributor

@gruebel gruebel commented Oct 27, 2020

Fixes aws-cloudformation/cloudformation-coverage-roadmap#77

Description of changes:
I added the possibility to add tags to the LogGroup resource.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@wbingli
Copy link
Contributor

wbingli commented Nov 3, 2020

Thanks for your contribution. We are prioritizing this PR review.

@miparnisari miparnisari removed the request for review from cdebojit November 3, 2020 17:42
@petewilcock
Copy link

+1 on this PR, we're awaiting this functionality 💯

@@ -128,4 +159,19 @@ static String buildResourceDoesNotExistErrorMessage(final String resourceIdentif
ResourceModel.TYPE_NAME,
resourceIdentifier);
}

static Map<String, String> translateTagsToSdk(final Set<Tag> tags) {
if (tags == null || tags.isEmpty()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tags.isEmpty() check is redundant. It should be handled by the stream() call

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will result in same error as below


static Map<String, String> translateTagsToSdk(final Set<Tag> tags) {
if (tags == null || tags.isEmpty()) {
return null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of returning null can we return an empty map?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if I don't return null here some of the contract tests will fail with

{'status': 'FAILED', 'errorCode': 'GeneralServiceException', 'message': "1 validation error detected: Value '{}' at 'tags' failed to satisfy constraint: Member must have length greater than or equal to 1 (Service: CloudWatchLogs, Status Code: 400, Request ID: 710f70c1-0dad-4f89-91ad-3eadd83b6e9c, Extended Request ID: null)", 'callbackDelaySeconds': 0}

ResourceModel.TYPE_NAME, model.getLogGroupName(), tagsToAdd);
logger.log(message);
}
} catch (final ResourceNotFoundException e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added one more exception handling, because the link provided is actually the wrong one, it is for CloudWatch not CloudWatch Logs. That's the correct one 😄
https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_TagLogGroup.html#API_TagLogGroup_Errors

@@ -43,7 +43,7 @@
<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>cloudwatchlogs</artifactId>
<version>2.13.18</version>
<version>2.15.26</version>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There have been issues with resource providers using newer AWS SDK versions than the Java plugin is using:
aws-cloudformation/cloudformation-cli-java-plugin#267 (comment)
aws-cloudformation/cloudformation-cli-java-plugin#324

Is the current AWS SDK version the Java plugin is using sufficient?

Suggested change
<version>2.15.26</version>
<version>2.15.19</version>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, changed it and moved the version to the properties section

@gruebel
Copy link
Contributor Author

gruebel commented Nov 24, 2020

@PatMyron is there anything else I should change or more feedback?

try {
response = proxy.injectCredentialsAndInvokeV2(Translator.translateToReadRequest(model),
ClientBuilder.getClient()::describeLogGroups);
ClientBuilder.getClient()::describeLogGroups);
tagsResponse = proxy.injectCredentialsAndInvokeV2(Translator.translateToListTagsLogGroupRequest(model.getLogGroupName()),
Copy link
Contributor

@wbingli wbingli Nov 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To have backward compatibility, the ListTagsLogGroups call should be soft-fail if no permission for tagging. Basically catch the permission error of this API call and ignore it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, I can add it, but I don't get why I should support here backward compatibility? Shouldn't I then do it everywhere, where I interact with tags in some way? I'm just really curious about it, hope to get some more insights 😄

Copy link

@PatMyron PatMyron Nov 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

particularly issues with ReadHandlers since permissions expand without customer changes. We have an internal issue to eventually find a platform-wide solution to this problem

Copy link
Contributor

@wbingli wbingli Dec 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gruebel Some users may not have tagging permissions while creating the log group resource before, especially they use stack role and restrict the permissions to operate a stack .

In this way, it will break people if this change go out. It makes senses to fail if users specify tags during create or update time. However, if they creates the log group successfully before, it will be bad experience to break them. BTW, the READ will be used for GetAtt function to get the attribute data as well as for drift detection for the resource.

Copy link
Contributor Author

@gruebel gruebel Dec 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the insight. Makes sense with the stach role permission for stack updates. I also used it in my previous work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm still curious about is, what is actually the List handler used for. The Read one I understand and it is used also during stack resource import, but the List one?!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This List handler is not used in CloudFormation yet, it intends for future features, so having it hard fail for permission issue is right to do.

final ResourceModel model = request.getDesiredResourceState();
final ResourceModel previousModel = request.getPreviousResourceState();
final boolean retentionChanged = ! retentionUnchanged(previousModel, model);
final boolean kmsKeyChanged = ! kmsKeyUnchanged(previousModel, model);
final boolean tagsChanged = ! tagsUnchanged(previousModel, model);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use getDesiredResourceTags which will combine both stack tags and resource tag. And getPreviousResourceTags for both previous stack tags and resource tags.

You will need to override the resourceDefinedTags (example) so that the getDesiredResourceTags will merge the stacks and resource defined tags together.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, makes sense and will try to add it.

@gruebel
Copy link
Contributor Author

gruebel commented Dec 16, 2020

@wbingli would be great to get some feedback for my new changes 😄

@gruebel gruebel requested a review from wbingli January 29, 2021 10:39
}
} catch (final ResourceNotFoundException e) {
throwNotFoundException(model);
} catch (final InvalidParameterException e) {
Copy link
Contributor

@wbingli wbingli Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to soft fail the Tag permission as well for Update and Create. The reason is that the Tagging change would comes from stack tags as well. The scenario is that some users don't give Tag permission to the stack. Before this change, the Log group resource can be update successful while doing stack tag update, as this resource just ignore any tag update.

With this change, it will now update the tag for cloudformation stack tags and it can run into permission error and fails the resource update. Soft fail with it as same as read handler can avoid breaking change to those users.

@jaglade
Copy link

jaglade commented Feb 22, 2021

Is there any update on this PR? We are eagerly awaiting this functionality.

@tata9001
Copy link

tata9001 commented Apr 1, 2021

Any update on this PR?

@Aleksandr-Filichkin
Copy link

Any update on this?

@vitali-pozniak
Copy link

+1

@mgmarino
Copy link

It'd be great to have input from either the reviewers or @gruebel (who has already put in a lot of work here, thanks!) about whether help from the community is desired to get this over the finish line. This is a very important feature improvement.

@JoryUK
Copy link

JoryUK commented May 7, 2021

+1

@wbingli
Copy link
Contributor

wbingli commented May 10, 2021

@sfbaker7 Any comment to this PR? I have only one comment here (#53 (comment)) to address.

@gruebel
Copy link
Contributor Author

gruebel commented May 10, 2021

sorry, everyone. I totally forgot about my PR 🙈

@wbingli I added the silent fail behaviour for add and remove tags, when trying to update a log group. Tagging permissions are not needed when creating a log group with tags.

@gruebel gruebel requested a review from wbingli May 11, 2021 09:32
@wbingli wbingli requested a review from ammokhov May 12, 2021 20:45
@wbingli
Copy link
Contributor

wbingli commented May 12, 2021

@gruebel Thanks for your contribution. Will merge it once we have other reviewer approve it.

@shoddyknight
Copy link

I am eagerly awaitiing this being merged so I can tag and find my cfn-init logs easily

@ammokhov ammokhov merged commit 5e7acf4 into aws-cloudformation:master May 20, 2021
@samjarrett
Copy link

Is this still yet to be deployed? It definitely isn't documented and doesn't work if you specify Tags: as a property...

@sfbaker7
Copy link
Contributor

sfbaker7 commented Jul 1, 2021

Hi, we are expecting this to be available in all regions by the end of next week. Documentation change will follow after

Will update this thread once deployed, apologies for the delay!

@glc-froussel
Copy link

Hello there, any update on this ?

@bool3012
Copy link

Any update?? This feature still doesn't work, at least in eu regions..

@felixfang
Copy link

Hi this is Felix from AWS, to add support of tags, our team need to go through security review to release it. We are currently working on the review.

@bencovi
Copy link

bencovi commented Aug 4, 2021

Hi @felixfang - any updates?

@felixfang
Copy link

felixfang commented Aug 6, 2021

Hi we are still working on the security review. We are aiming to have it ready in September

@felixfang
Copy link

felixfang commented Sep 27, 2021

Hi Sam, just and update. The security review is in good progress, we just need some more weeks to close it so we can pull your request into our code. We will try complete Tag support in Oct. Sorry for delaying on this.

@Karthi96
Copy link

Karthi96 commented Nov 8, 2021

@felixfang any update on this, when this can be released?

@reply2srij
Copy link

Can we get an update on this please?

@glc-froussel
Copy link

Can we get an update on this please?

It has been released on November 22 ;)

@SeijiSuenaga
Copy link

Is it just me, or are stack-level tags not always applied to log group resources in the stack? I'm seeing inconsistent results where log groups don't always (but sometimes do) have all the tags that are on the stack.

@glc-froussel
Copy link

Is it just me, or are stack-level tags not always applied to log group resources in the stack? I'm seeing inconsistent results where log groups don't always (but sometimes do) have all the tags that are on the stack.

I had the same behaviour and the cause was that I had to explicitly create the log group resource in the CF template instead of having the related resource create it (aka, the log group must be part of your stack resources).

Maybe you are facing the same issue ?

@mgmarino
Copy link

mgmarino commented Jan 5, 2022

Is it just me, or are stack-level tags not always applied to log group resources in the stack? I'm seeing inconsistent results where log groups don't always (but sometimes do) have all the tags that are on the stack.

CF will only propagate changes. In other words, if you have stack-level tags and they have not changed since this feature was introduced, they will not get propagated to the log groups. For already existing stacks, this was an issue for us since we have some tags that do not regularly change on deployments. (Some, like the Version, do, and these were getting propagated as expected.) To force the tags to get propagated, we had to do some manual deployments setting the tags to a temporary value (note, just omitting them will not "delete" them), and then a subsequent deployment with the correct tag values.

@SeijiSuenaga
Copy link

Is it just me, or are stack-level tags not always applied to log group resources in the stack? I'm seeing inconsistent results where log groups don't always (but sometimes do) have all the tags that are on the stack.

CF will only propagate changes. In other words, if you have stack-level tags and they have not changed since this feature was introduced, they will not get propagated to the log groups. For already existing stacks, this was an issue for us since we have some tags that do not regularly change on deployments. (Some, like the Version, do, and these were getting propagated as expected.) To force the tags to get propagated, we had to do some manual deployments setting the tags to a temporary value (note, just omitting them will not "delete" them), and then a subsequent deployment with the correct tag values.

Thank you, that's exactly what's happening in my case, so I'll have to do some manual shenanigans too unfortunately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AWS::Logs::LogGroup tag support